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This  effort  was  conducted  in  response  to  problems  discussed  in  General  Accounting 
Office  Report  PSAD-81-17  and  Naval  Research  Advisory  Committee  Report  80-9  con¬ 
cerning  the  lack  of  emphasis  and  effective  use  of  human  factors  engineering  (HFE) 
technology  during  the  weapon  system  acquisition  process.  The  development  of  a  HFE  data 
base,  the  characteristics  of  which  are  described  in  this  report,  should  assist  designers  in 
utilizing  HFE  inputs.  The  research  is  sponsored  by  the  Naval  Sea  Systems  Command  as 
part  of  its  program  for  Human  Factors  Engineering  Technology  for  Surface  Ships,  SF57- 
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SUMMARY 


Problem 


Many  major  Navy  weapon  systems  are  developed  without  the  aid  of  human  factors 
engineering  (HFE)  inputs,  resulting  in  systems  that  are  difficult  to  operate,  are  prone  to 
personnel  error,  and  have  reduced  operational  effectiveness.  One  reason  for  this  is  the 
lack  of  an  HFE  data  base  to  which  designers  and  program  managers  can  refer  for  answers 
to  behavioral  questions  that  arise  during  weapon  system  development  and  acquisition. 

Objective 

The  overall  objective  of  the  project  is  to  develop  an  HFE  data  retrieval  support 
system  for  hardware  system  acquisition  managers  and  designers.  The  immediate  goal  of 
the  effort  presented  herein  was  to  specify  the  characteristics  of  the  proposed  HFE  data 
base. 

Approach 

This  effort  was  organized  around  the  development  of  a  data  system  that  would  (1) 
supply  information  responsive  to  the  needs  of  a  wide  variety  of  users  including  managers, 
designers,  and  HFE  specialists,  (2)  include  data  of  the  type  presently  available  in  MIL  STD 
1472C,  plus  quantitative  estimates  of  human  performance  data  for  prediction  of  personnel 
effectiveness,  maintenance  and  logistics  data,  specifications  and  standards,  analytic  and 
evaluational  techniques,  and  (3)  include  data  from  operational  (Navy)  sources  not 
presently  found  in  any  HFE  data  base. 

Results 

The  proposed  HFE  data  system  should  consist  of: 

1.  Three  types  of  data,  with  Track  1  consisting  of  abstracts  of  individual  studies, 
Track  2  containing  data  from  the  same  sources  presented  in  a  highly  synthesized  and 
compressed  form,  and  Track  3  containing  all  other  ancillary  information  such  as  HFE 
specifications  and  standards.  There  should  be  a  distinctive  format  for  each  track. 

2.  Data  from  a  wide  variety  of  sources  such  as  fleet  exercises,  simulators, 
laboratory  studies,  subjective  judgments,  and  design-support  studies. 

3.  A  three-tier  taxonomy  for  (a)  human  performance  represented  by  process, 
function,  and  generic  task  and  (b)  equipment  represented  by  class,  type,  and  subtype. 

Recom  men  dat  ions 


1.  Initiate  the  development  of  the  HFE  system  as  a  multiyear  effort  in  accordance 
with  guidelines  presented  herein. 

2.  Implement  multiple  concurrent  contracts  for  the  development  of  the  system. 

3.  Pursue  the  development  of  the  operational  data  sources  that  should  provide  much 
of  the  information  in  the  system. 
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INTRODUCTION 


Problem 


Many  major  Navy  weapon  systems  are  developed  without  the  aid  of  human  factors 
engineering  (HFE)  inputs,  resulting  in  systems  that  are  difficult  to  operate,  are  prone  to 
personnel  error,  and  have  reduced  operational  effectiveness.  One  reason  for  this  is  the 
lack  of  an  HFE  data  base  to  which  designers  and  program  managers  can  refer  for  answers 
to  behavioral  questions  that  arise  during  weapon  system  development  and  acquisition. 

Objective 

The  overall  objective  of  the  project  is  to  develop  an  HFE  data  retrieval  support 
system  for  hardware  system  acquisition  managers  and  designers.  The  immediate  goal  of 
the  effort  presented  herein  was  to  specify  the  characteristics  of  the  proposed  HFE  data 
base. 

Background 

An  HFE  data  base  is  the  organized  compre  hensive  compilation  of  quantitative  and 
qualitative  data  that  describe  how  the  behavioral  principles  function  in  the  design, 
development  and  operation  of  a  man-machine  system  (MSS).  The  data  base  may  include 
either  quantitative  (numerical)  data  or  qualitative  (nonnumerical)  data  derived  from 
quantitative  data.  In  either  case,  the  data  refer  directly  to  or  imply  some  human 
performance  involved  in  the  operation  and  maintenance  of  the  MMS. 

There  are  two  reasons  for  developing  an  HFE  data  base.  First,  HFE  specialists  need 
an  HFE  data  base  to  develop  adequate  HFE  design  recommendations.  Second,  hardware 
project  engineers  and  designers  are  reluctant  to  utilize  HFE  data  and  inputs  because  they 
are  not  organized  in  an  easily  retrievable  form.  Consequently,  many  major  Navy  weapon 
systems  are  developed  without  HFE  advice  and  data. 

The  impetus  behind  the  construction  of  a  HFE  data  base  is,  therefore,  to  secure  more 
HFE  inputs  into  Navy  hardware  system  development.  The  assumption  is  that,  if  an 
effective  HFE  data  base  existed,  more  adequate  answers  could  be  given  to  the  many  HFE 
questions  that  arise  during  system  development.  This,  in  turn,  would  prompt  managers 
and  designers  to  incorporate  these  answers  into  design. 

In  proposing  an  HFE  data  bank,  the  objection  that  there  are  already  compilations  of 
data  that  could  satisfy  this  need  must  be  addressed.  In  fact,  no  effective  HFE  data  bank 
presently  exists,  despite  numerous  efforts  to  develop  one.  For  example,  Reed,  Snyder, 
Baran,  Loy,  and  Curtin  (1975)  attempted  to  create  a  data  bank  based  on  logistics 
information  available  in  Air  Force  documents.  Munger,  Smith,  and  Payne  (1962)  published 
a  data  bank  based  on  the  probability  of  error  in  operating  common  controls  and  displays. 
Blanchard,  Mitchell,  and  Smith  (1966)  developed  a  special  data  bank  based  on  "expert" 
opinions. 
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Most  compilations  of  HFE  data  are  in  the  form  of  books  (e.g.,  Woodson,  1981;  Van 
Cott  &  Kinkade,  1972).  However,  such  books  fail  to  satisfy  the  needs  for  a  HFE  data  bank 
because: 

1.  They  are  organized  as  job  tools  and  not  in  terms  of  HFE  problems  for  which 
certain  information  is  needed  and  can  be  retrieved. 

2.  The  material  they  present  is  not  comprehensive,  because  books  are  highly 
selective  in  the  references  they  cite  and  the  material  they  present. 

3.  Books  often  present  summaries  of  the  data  rather  than  the  data  themselves. 

4.  Nonspecialists  rarely  use  HFE  books  as  references  (Meister  &  Farr,  1967). 
Almost  all  the  materials  provided  for  use  by  nonspecialists  are  used  only  by  specialists. 


5.  The  material  presented  comes  usually  from  academic  sources  rather  than  from 
operational  situations. 

APPROACH 


This  effort  was  organized  around  the  development  of  a  data  system  that  would  (1) 
supply  information  responsive  to  the  needs  of  a  wide  variety  of  users  including  managers, 
designers,  and  HFE  specialists,  (2)  include  data  of  the  type  presently  available  in  MIL  STD 
1472C,  plus  quantitative  estimates  of  human  performance  data  for  prediction  of  personnel 
effectiveness,  maintenance  and  logistics  data,  specifications  and  standards,  analytic  and 
evaluational  techniques,  and  (3)  include  data  from  operational  (Navy)  sources  not 
presently  found  in  any  HFE  data  base. 

Definition  of  HFE  Data  and  Data  Banks 

HFE  data  describe  how  personnel  perform  or  might  perform  in  a  work-oriented 
context  and  how  nonbehavioral  factors  such  as  equipment,  procedures,  job  design,  or 
manuals  affect  personnel  performance.  HFE  data  are,  in  most  cases,  quantitative  but 
may  include  relevant  qualitative  material  such  as: 

1.  Verbal  material  describing  the  context  of  the  studies  from  which  numerical 
values  (data  in  the  "pure"  sense)  are  derived. 


2.  The  conclusions  derived  from  the  data. 

3.  The  design  implications  and  recommendations  stemming  from  the  conclusions. 

4.  Ancillary  useful  information  whether  or  not  derived  from  empirical  studies  (e.g., 
listing  of  HFE  specifications  and  standards,  HFE  reference  texts,  etc.). 


All  of  these  are  considered  HFE  data  in  a  larger,  more  general  sense. 

An  HFE  data  bank  is  a  comprehensive  compilation  of  data  organized  according  to 
specified  principles  to  answer  specified  questions.  It  is  not  a  random  collection  or  a 
representative  sample  of  data.  The  data  bank's  purpose  determines  which  data  are 
incorporated  into  he  bank  and  which  are  rejected.  All  data  bearing  on  the  topic  or  topics 
for  which  answers  are  desired  that  meet  certain  criteria  of  data  quality  (e.g.,  size  of 


subject  sample,  lack  of  data  confounding,  etc.)  are  incorporated  into  the  bank.  A  data 
bank  ad  so  includes  a  specified  formal  and  systematic  method  of  using  the  data  bank  (e.g., 
instructions  for  using,  indexing,  and  retrieving  the  desired  data).  Often  the  data  in  the 
data  bank  have  been  modified  from  the  form  initially  derived  from  the  original  empirical 
study.  For  example,  when  data  from  several  studies  are  combined  into  a  single  table  or 
graph,  the  data  metric  may  be  modified  to  a  common  base;  data  values  may  be 
adjusted — as  the  developers  of  the  Data  Store  (Payne  <Sc  Altman,  1962)  did--to  make  them 
more  representative  of  the  situations  to  which  they  will  be  applied.  Another 
characteristic  of  the  data  bank  is  that  the  data  are  presented  to  the  user  in  a  standardized 
format,  although  there  may  be  several  variations.  Therefore,  a  data  bank  is  much  more 
than  merely  the  presentation  of  a  series  of  study  abstracts,  although  some  part  of  the 
data  bank  may  consist  of  that  also.  Finally,  a  data  bank  was  visualized  herein  as  a  tool 
developed  for  use  by  HFE  specialists  and  others  in  the  general  population  and  not 
developed  solely  to  meet  the  need  of  an  individual  researcher. 

System  Development  Questions 

Certain  questions  arise  during  system  development,  which  starts  when  a  new  system 
is  first  conceived  and  ends  when  it  is  handed  over  to  the  customer  for  operational  use. 
These  questions  arise  as  a  natural  consequence  of  the  way  in  which  development  unfolds. 
If  the  data  system  is  to  be  maximally  useful,  it  should  be  established  to  assist  in  answering 
these  questions,  although  the  questions  themselves,  being  specific  to  the  new  system, 
cannot  be  answered  wholly  by  the  data  system.  The  following  questions  are  modified  from 
Meister  (1982): 

System  Planning  Phase 

1.  What  changes  in  the  new  system,  as  distinct  from  its  predecessor,  require 
changes  in  the  number  and  types  of  personnel  needed  to  run  the  system? 

2.  What  changes  in  the  task  to  be  performed  in  the  new  system  will  require  changes 
in  personnel  selection,  training,  and  operations? 

3.  In  other  words,  what  will  be  the  impact  of  the  new  system  upon  the  military's 
personnel  responsibilities  and  how  can  this  impact  be  minimized? 

Predesign  Phase 

1.  Which  of  the  various  design  alternatives  suggested  to  satisfy  the  system 
requirement  is  most  effective  from  a  human  performance  standpoint? 

2.  Will  system  personnel  be  able  to  perform  all  required  functions  effectively  in  the 
new  system  in  the  time  available  to  them?  Will  they  be  able  to  achieve  the  criterion  of 
required  performance  if  such  a  criterion  exists? 

3.  What  workload  will  personnel  encounter  and  will  any  part  of  that  workload  be 
excessive? 


4.  Given  that  the  new  system's  error  probability  has  been  determined,  what  are  the 
factors  responsible  and  can  it  be  reduced  by  changing  the  design  configuration? 


Detail  Design  Phase 


1.  Which  is  the  better  or  best  of  two  or  more  alternative  subsystem  or  component 
configurations? 

2.  What  level  of  personnel  performance  can  one  achieve  with  that  design  configura¬ 
tion  and  does  that  level  satisfy  system  requirements? 

3.  Are  there  any  design  elements  tnat  could  stress  personnel  and  lead  to  excessive 
error? 

4.  Considering  the  new  detailed  design  configuration,  can  previous  est:  *es  of 
number  and  skill  remain  unchanged? 

5.  What  kind  of  training  should  personnel  receive? 

6.  Are  the  equipment  design  and  the  procedures  for  its  use  properl  1  nan 
engineered"?  Are  there  any  significant  flaws  that  must  be  rectified  before  the  ,*gn  in 
accepted? 

Test  and  Evaluation  Phase 

1.  Have  all  the  system  aspects  affected  by  behavioral  variables  been  properly 
"human  engineered"? 

2.  Will  the  operator/maintainer  be  able  to  do  his/her  job  effectively  with  the 
system  as  configured? 

Operational  Testing  Phase 

1.  From  the  standpoint  of  personnel  performance,  does  the  system  meet  require¬ 
ments? 

2.  What  existing  design  inadequacies  must  be  modified  to  render  the  system  more 
effective? 

Data  Requirements 

Blanchard  (1973)  discussed  the  kinds  of  data  that  will  assist  in  answering  these 
questions: 

A  number  of  various  data  requirements  were  identified  for  two 
major  classes  of  users:  (1)  planners/directors/managers  (PDM);  and 
(2)  human  factors  and  design  engineering  specialist  (HFDE).  These 
needs  are  listed  below  with  a  reference  to  the  associated  user  group. 

(1)  System,  subsystem  and  function  baseline  data  on  current 
systems  with  measures  of  personnel  performance  related  to  overall 
system  performance  for  use  in  contrasting  current  capabilities 
against  potential  capability  increments  of  new  proposed  systems. 

(PDM) 
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(2)  Data  on  the  relationship  between  such  personnel  back¬ 
ground  factors  as  educational  level,  AGCT  scores,  personnel  category 
level  (I,  II,  III,  IV),  and  on-the-job  performance  measures  on  various 
system  tasks  for  use  in  performance  prediction  and  assignment. 
(PDM). 

(3)  Training  time  data  (formal  and  OJT)  for  various  personnel 
classes  to  reach  current  or  required  performance  levels  on  various 
personnel  functions  found  in  current  systems.  Used  in  evaluating 
training  impact  of  new  systems.  (PDM) 

(4)  Personnel  requirements  (standards)  data  associated  with 
critical  personnel  activities  for  various  systems.  Achievement  of 
standards  should  ensure  attaining  a  prescribed  level  of  system  perfor¬ 
mance.  (PDM) 

(5)  Personnel  readiness  or  preparedness  data  for  various  tasks 
on  operational  systems  collected  over  time  in  order  to  determine 
performance  levels  and  degree  of  performance  variability  within  and 
between  people  (positions)  and  teams.  Used  for  identifying  remedial 
training  requirements  and  for  appraising  personnel  capabilities  to 
perform  tasks  to  the  levels  required  in  a  new  systems  approach. 
(PDM) 

(6)  Normative  personnel  performance  data  for  specific  system 
functions  for  various  ships,  missions,  and  operational  conditions. 
Used  to  assess  relative  preparedness  for  feedback  in  team  and 
individual  training  efforts  and  in  defining  system  employment  guide¬ 
lines.  (PDM;  tactical  commanders) 

(7)  Shipboard  work  standards  and  performance  time  baseline 
data  for  such  shipboard  activities  as  utilities  tasks,  administrative 
support  tasks,  facilities-maintenance  tasks,  and  watchstanding  tasks. 
(HFDE) 

(8)  Performance  data  on  a  time  dimension  (response  time, 
execution  time,  completion  time,  reaction  time)  at  task,  task  step, 
and  task  element  levels  of  specificity  for  operator,  maintainer,  and 
service-support  type  tasks.  Used  primarily  in  operator  work 
load/time  stress  analyses  and  in  determining  effective  operation  of 
display/control  consoles.  (HFDE) 

(9)  Continuously  distributed  capability  data  illustrating  func¬ 
tional  relations  between  various  human  behavioral  processes  and 
equipment,  task  and  environmental  parameters.  Used  in  tradeoff 
analyses  and  in  generating  specifications  for  various  system  elements 
in  terms  of  specific  parameters  with  known  relations  with  human 
performance.  (HFDE) 

(10)  Operator  performance  data  at  function  and  task  levels  for 
various  "critical"  man-machine  design  interfaces  and  task/environ¬ 
ment  conditions  (information  processing/decision  making).  Needed  to 


seek  a  better  match  in  design  between  operator  and  system  capabil¬ 
ities  to  enhance  overall  effectiveness  (level  of  automation). 
(HFDE/PDM) 

(1L)  General  human  capability  data  at  the  major  function  level 
for  various  design  approaches  to  enable  a  design  team  to  compile  and 
review  such  information  and  anticipate  possible  problems  that  might 
occur  in  a  new,  proposed  systems  approach  which  should  be  given 
special  attention  in  design.  (PDM/HFDE) 

(12)  Elapsed-time  data  for  human  transportation/locomotion 
activities  for  various  departure/arrival  points  and  shipboard  config¬ 
urations.  Used  in  workload  analyses  and  studies  requiring  spatial 
information,  transport  links,  and  traverse  times  under  normal  and 
abnormal  conditions.  (HFDE) 

(13)  Team  performance  data  for  various  types  of  systems,  crew 
configurations,  and  environmental  and  operating  conditions.  Used  in 
studying  situations  and  designing  systems  in  which  several  individuals 
perform  certain  functions  in  an  integrated  manner.  (PDM/HFDE) 

(14)  Engineering  design  data  illustrating  the  relation  between  a 
wide  range  of  specific  hardware  components  with  various  physical 
characteristics  and  human  performance  levels.  Used  in  selecting 
among  alternative  hardware  components  for  system  use.  Also  need 
component  cost  and  reliability  data.  (HFDE) 

(15)  To  the  fullest  extent  possible,  the  store  should  include  data 
on  such  environmental  parameters  as  temperature,  illumination, 
noise,  vibration,  ship  (aircraft)  motion,  space  limitations,  and  so  forth 
in  relation  to  performance.  Where  possible,  such  factors  should  be 
related  to  a  physiological  criterion  such  as  hearing  loss,  visual 
attenuation,  nausea,  and  so  forth.  (HFDE) 

(16)  Personnel  cost  data  and  related  information  to  support 
relative  cost/effectiveness  tradeoff  studies  during  system  design  and 
development  and  in  appraising  alternative  routes  for  upgrading  cur¬ 
rent  systems.  (PDM/HFDE)  (pp.  9-11) 


Characteristics  of  Anticipated  Users 

A  data  system  that  is  not  utilized  is  in  effect  worthless.  One  must  therefore  be 
concerned  about  the  anticipated  user  of  the  proposed  system  because  the  system  must  be 
designed  to  match  as  much  as  possible  the  characteristics  of  the  user. 

Blanchard  (1972)  surveyed  the  following  potential  Navy  users  of  a  HFE  data  system: 

1.  Planners/policymakers. 

2.  Project/program  managers. 

3.  Hardware  design  engineers. 

4.  Reliability/maintainability  engineers. 

5.  HFE  specialists. 
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These  job  specialities  cover  a  very  wide  •'ectrum  in  terms  of  amount  of  behavioral 
training  and  knowledge  and  interest  in  HFE.  However,  it  can  be  asssumed  that  all  users, 
except  for  HFE  specialists,  are  laymen  with  minimal  interest  in  and  knowledge  of  HFE. 
Any  HFE  data  system  addressed  to  both  laymen  and  specialists  faces  certain  difficulties 
in  terms  of  the  demands  that  can  be  imposed  on  each  in  securing  information.  Whereas 
specialists  may  desire  very  detailed  information  about  a  particular  topic  and  accept 
complexity  and  the  necessity  of  analyzing  information  to  secure  an  answer,  laymen  prefer 
their  information  in  simple,  easy-to-understand  form;  directly  applicable  to  their  problem; 
and  without  the  necessity  of  analyzing  data  to  secure  a  precise  answer.  Such  a 
discordance  begs  for  a  two-track  data  format- -one  designed  for  laymen  and  the  other,  for 
specialists. 

However,  equal  emphasis  need  not  be  given  to  both  laymen  and  specialists.  Any 
organization  with  an  HFE  specialist  would  probably  expect  the  specialist  to  supply  most  of 
the  behavioral  data  and  information.  Very  few  policy  makers  or  design  engineers  would 
personally  address  the  HFE  data  system,  if  they  could  simply  ask  the  specialist  for  the 
information.  From  that  standpoint,  greater  emphasis  should  be  placed  on  having  the  data 
system  serve  HFE  specialists  rather  than  the  laymen.  At  the  same  time,  the  latter  cannot 
be  ignored. 

Data  Sources 


Table  1  presents  potential  sources  of  data  for  the  HFE  data  system. 
Data  Selection  Criteria 


Theoretically,  the  HFE  data  system  should  include  data  from  all  relevant  studies. 
However,  considerations  of  technical  adequacy,  cost,  and  time  make  such  a  goal 
unfeasible.  When  the  data  system  includes  all  relevant  studies,  the  value  of  each  study  is 
implicitly  accepted  as  being  equal  to  that  of  every  other  study.  This  is,  of  course,  quite 
incorrect  because  some  studies  have  defects  that  reduce  their  value.  When  weak  studies 
are  explicitly  included  in  the  data  system,  the  system  user  may  wonder  why  they  were 
included  and  their  presence  may  confuse  him.  Some  selectivity  in  the  material 
incorporated  into  the  data  system  is  necessary. 

All  other  things  being  equal,  data  from  the  most  recently  published  studies  should  be 
included  first.  How  far  back  to  go  in  time  presents  a  pragmatic  problem.  Another 
problem  is  that  not  all  studies  are  of  equal  value.  For  instance,  what  should  be  done  about 
a  study  published  more  than  20  years  ago  that  is  a  classic  in  its  field?  Deference  to 
quality  suggests  ignoring  the  arbitrary  time  limitations  in  this  case.  This  situation  applies 
mostly  to  published  studies  but  may  also  occur  when  data  from  a  Navy  activity  was 
previously  published  in  a  report. 

One  primary  criterion  of  data  selection  is  that  the  data  must  contain  an  explicit  or 
implied  reference  to  human  performance.  For  example,  a  study  dealing  with  questions  of 
maintenance  (e.g.,  maintenance  philosophy  such  as  remove/replace  versus  remove/re¬ 
place/repair)  might  be  included  in  the  data  system  if  the  maintenance  philosophy  had 
implications  for  the  training  or  performance  of  naval  technicians--the  more  direct  the 
reference  to  human  performance,  the  more  valuable  the  study.  Of  course,  the  human 
performance  to  which  the  data  refer  must  be  work-oriented  performance  in  a  man- 
machine  context.  A  study  of  decision  making  processes  of  subjects  solving  paper-and- 
pencil  economic  problems  would  not  satisfy  this  criterion. 


Potential  Sources  of  Data  for  HFE  Data  System 


Data  Source 


Limitations/Remarks 


Likelihood  of 
Securing  Desired 
Data  from  Source 


I.  Operational  system  using  instru¬ 
mentation  that  records  and 
measures  selected  activities 
automatically  (in  real  time) 
without  human  participation  and 
is  not  visible  to  system  person¬ 
nel. 


Instrumentation  can  record  only  control  manipulations.  Eye 
movement  data  could  be  collected,  but  it  would  be  prohibitively 
expensive.  Instrumentation  provides  no  cognitive  data.  The 
availability  of  such  data  is  unknown.8 


Poor 


2.  Human  performance  data  col-  Attempts  to  collect  data  during  exercises  had  limited  success.  Poor 

lected  during  fleet  exercises.  Several  respondents  to  Blanchard's  survey  (1972)  indicated  such 

data  are  not  taken  too  seriously  because  of  the  data  collection 
method  used.  Typically,  observers  are  used,  which  introduces 
subjectivity  and  bias.  Most  data  are  collected  at  the  major 
function  level,  which  typically  is  too  molar  to  be  used  in 
system  design  applications.  Data  would  be  more  useful  if  the 
data  co'.ection  agency  could  participate  more  with  the  Navy 
activity  responsible  for  the  conduct  of  these  exercises. 


3,  Dynamic  simulation  studies 
conducted  for  personnel  train¬ 
ing  or  for  evaluating  display/ 
control  or  other  system  designs. 


9.  Military-related  laboratory 

studies  conducted  to  investigate 
specific  problems  irvder  con¬ 
trolled  conditions. 


5.  “Directed"  data  collection 
studies. 


6.  Experimental  research  literature. 


7,  Subjective  judgment  studies. 


S.  Design-support  studies. 


9.  Nonperformance  data,  which  are 
not  really  data  as  such. 


Simulator  studies  are  considerably  more  realistic  than  are  most  Poor 

studies,  but  their  cost  often  limits  their  use.  Often, 

simulator  managers  resist  using  their  simulators  to  collect 

these  data,  even  though  data  collection  need  not  interfere 

with  the  simulators'  primary  purpose.  The  experimental  design 

of  the  study  must  ensure  gathering  of  statistically  acceptable 

data. 


Laboratory  studies  are  designed  to  include  variables,  levels,  Good,  as  these  studies 

and  conditions  that  reflect  the  operational  context.  Hence,  are  usually  published 

the  data  obtained  would  reflect  the  experimenter's  recognition  and  generally  available, 

of  the  need  for  generalizing  to  the  operational  environment. 

In  many  instances,  the  data  might  be  for  a  specific  system. 


Blanchard  (1973)  proposed  this  highly  specialized  potential  Poor 

data  source  based  on  the  assumptions  that  (1)  a  Navy  store  program 
eventually  will  be  initiated  and  (2)  such  a  program  would 
be  directed  by  an  administrative  agency/activity  (e.g.,  NAV- 
PERSRANDCEN).  This  agency  could  routinely  determine  if  any 
areas  within  the  data  store  are  weak  or  lack  required  perfor¬ 
mance  data.  If  the  necessary  data  are  not  available  from  other 
sources,  the  agency  could  initiate  and  fund  its  own  studies 
according  to  detailed  specifications. 


Considered  by  most  Navy  HF  specialists  to  be  an  essentially  High,  although  usability 

invalid  source  of  data  for  applied  work  in  Navy  systems  will  probably  vary  widely, 

because  most  experiments  are  conducted  under  artificial  condi¬ 
tions  and  also  emphasize  hypothesis  testing  (Blanchard,  1972). 

Studies  are  often  contrived  to  test  only  the  extremes  of  a 
distribution  that  far  exceed  any  values  experienced  in  practical 
applications.  Therefore,  such  studies  have  limited  utility 
in  the  real  world. 

Such  data  might  be  useful  if  considered  carefully  within  their 
collection  conditions.  All  moderator  variables  (performance 
shaping  factors)  coded  into  the  data  store  should  be  carefully 
appraised  for  each  study.  If  such  factors  are  carefully  noted, 
data  system  users  could  employ  the  related  data.  Despite  these 
reservations,  it  is  anticipated  that  the  proposed  data  system 
will  be  based  largely  on  data  from  this  source  because  alternative 
sources  are  either  unavailable  or  extremely  difficult  to  utilize. 


Because  of  the  lack  of  current  human  performance  data  to  deal  Excellent,  if  money  is 

with  various  human  performance  problems,  various  subjective  available  to  collect  the 

techniques  will  probably  be  required  to  obtain  the  necessary  necessary  data, 

input  data.  Techniques  involving  "expert"  judgment  have  been 
used  by  a  number  of  human  performance  researchers  (e.g., 

Blanchard  et  al.,  1966;  Irwin,  Levitz,  fit  Freed,  I960;  and 
Embrey,  1981).  Those  asked  to  provide  judgmental  data  should  be 
experts  on  the  questions  they  are  asked  to  answer.  Research  to 
assess  the  validity  of  such  techniques  for  data  collection  is 
quite  limited.  Conducting  formal  validation  would  be  highly 
desirable  before  such  techniques  are  accepted  as  potential 
sources  of  data  system  information. 


Relatively  informal  studies  are  sometimes  performed  during  Slight 

system  design  and  development  to  obtain  guidance  on  specific 
design  questions  or  problems.  Design-support  studies  are 
usually  brief,  involve  minimum  time  and  effort,  and  seldom  re¬ 
port  their  resulting  data  formally.  If  data  from  these  studies 
can  be  retrieved  and  carefully  screened,  organized,  and  for¬ 
matted,  these  data  are  a  potential  source  of  input  data  for  a 
data  system  program.  Contractors  would  need  funding  to  write 
their  studies  up  according  to  a  data  store  specification. 


These  sources  include  information  about  such  topics  as  personnel  Excellent 
cost,  HFE  specifications  and  standards,  analytical  and  evalua¬ 
tion!  techniques,  and  habitability  design  principles.  Almost  all 
such  information  is  already  within  the  literature;  it  is  merely 
necessary  to  dig  it  out. 


*The  operational  performance  recording  and  evaluation  system  fOPREDS),  which  was  developed  by  the  Navy  Electronics  Laboratory 
Center,  was  not  equal  to  its  task  and  was  discarded.  No  other  such  Navy  system  is  known  to  exist.  At  least  one  civilian  system  in 
existence  is  the  General  Physics  Corporation’s  performance  measurement  system  for  collecting  nuclear-power-plant  control  room 
trainer  data. 


The  notion  that  one  selects  data,  accepting  some  and  rejecting  some,  presupposes  a 
concept  that  data  have  relative  value:  Some  data  are  better  than  other  data.  This 
concept  includes  the  following  criteria: 

1.  Relevance.  Refers  to  the  questions  that  may  arise  during  system  development 
and/or  to  the  particular  types  of  data  desired  by  potential  system  users. 

2.  Technical  quality.  Refers  to  the  confidence  one  can  place  in  the  data  derived 
from  a  particular  study.  This  confidence  is  achieved  by  considering  the  adequacy  of  study 
design,  size  of  subject  population,  similarity  of  subject  population  to  Navy  population, 
similarity  of  study  context  to  Navy  operational  context,  and  adequacy  of  measures  taken. 

When  Blanchard  (1972)  asked  potential  users  of  a  data  system  for  the  qualities  they 
desire  in  such  a  system,  they  responded  that  they  want,  among  other  things,  the  capability 
to  judge  the  validity,  applicability,  and  generalizability  of  the  data.  The  relevance 
criterion  earn  deal  at  least  partly  with  applicability  and  generalizability,  but  difficulties 
arise  with  the  validity  criterion.  It  seems  unlikely  that,  at  least  initially,  the  system  will 
provide  indications  of  validity,  since  the  term  validity  presumes  some  sort  of  external 
check  of  the  data  in  the  operational  environment.  Almost  no  behavioral  data  gathered  in 
laboratory  studies  have  been  checked  in  this  manner. 

The  application  of  criteria  to  the  selection  of  data— -assuming  that  it  is  necessary  to 
select-raises  logistical  problems  of  some  consequence.  Personnel  developing  the  system 
will  need  a  detailed  judgment  methodology  to  make  fairly  complex  judgments  of  relevance 
and  technical  adequacy  (e.g.,  some  form  of  rating  scale  and  some  means  of  aggregating 
values  of  multiple  criteria).  Although  this  should  not  pose  a  serious  difficulty,  it  will 
require  using  highly  qualified  senior  personnel  for  the  data  selection  process  and  possibly 
for  the  further  synthesizing  of  data  and  writing  of  abstracts  as  well.  Since  these  are 
complex  judgments,  where  the  possibility  of  judgment  error  is  very  real,  at  least  two  or 
even  three  judges  will  be  needed  to  ensure  adequate  consistency.  All  of  this  increases  the 
cost  because  reading  and  evaluating  studies  takes  considerable  time  and  senior  personnel 
are  fairly  expensive.  It  is  estimated  that  even  skilled  personnel  will  need  at  least  1  hour 
for  review,  analysis,  and  data  abstraction  of  a  single  study. 

Data  Taxonomy 


A  taxonomy  is  a  system  for  categorizing  or  classifying  the  items  in  the  data  base. 
Without  such  a  taxonomy,  it  is  impossible  to  create  a  data  base.  The  taxonomy  also 
serves  as  a  data  input  and  retrieval  mechanism  because  the  questions  the  user  asks  of  the 
data  system  must  be  phrased  in  terms  of  the  data  base  taxonomy.  Consequently,  what  is 
retrieved  from  the  data  base  is  phrased  in  terms  of  that  same  taxonomy. 

Development  of  a  data  base  taxonomy  is  a  heuristic  process  that  is  responsive  to  (i.e., 
matches)  the  special  questions  that  data  base  is  designed  to  answer.  There  is  no 
universally  accepted  behavioral  taxonomy;  indeed,  the  development  of  an  optimal  taxo¬ 
nomy  was  the  subject  of  a  3-year  study  program  by  Fleishman  and  his  colleagues 
(Fleishman  &  Stephenson,  1970).  Moreover,  no  single  taxonomy  is  sufficiently  compre¬ 
hensive  to  encompass  all  the  variables  involved  in  or  affecting  human  performance  and 
HFE;  if  it  were,  it  would  be  impossibly  complex  and  cumbersome. 


Taxonomies  have  been  developed  for  human  reliability  prediction  (Munger,  Smith,  dc 
Payne,  1962;  Berliner,  Angell,  <3 c  Shearer,  1964;  Meister  <St  Mills,  1971;  Finley,  Obermayer, 


Bertone,  Meister,  <5c  Muckier,  1970)  and  for  use  in  classifying  error  in  nuclear  power  plants 
(Rasmussen,  1981;  Topmiller,  Eckel,  <5c  Kozinsky,  1982). 


RESULTS 


Taxonomy 

The  taxonomy  adopted  for  this  efiort  follows  Blanchard's  (1973),  which  was  in¬ 
fluenced  by  Berliner  et  al.  (1969)  and  by  Meister  and  Mills  (1971).  This  three-tier 
taxonomy  permits  classification  at  the  process,  function,  and  generic  task  levels  and 
permits  the  user  to  scan  the  data  base  at  various  levels  of  detail,  starting  with  the  molar 
level  and  moving  down  to  the  more  detailed  levels. 

This  taxonomy  is  a  "top-down"  scheme,  starting  as  the  most  molar  level  of  behavior 
and  equipment  and  progressively  breaking  that  level  down  to  its  components.  In 
classifying  human  performance,  the  following  scheme  is  used: 

1.  Process  (e.g.,  perceptual,  perceptual-motor,  motor,  cognitive,  etc.), 
a.  Function  (e.g.,  visual,  auditory,  discrete,  continuous,  etc.). 

(1)  Generic  task  (e.g.,  detect  presence  of  one  or  more  stimuli). 

In  classifying  equipment,  the  breakout  would  be  as  follows: 

1.  Class  (e.g.,  visual  displays,  controls,  communications  equipment,  etc.), 
a.  Type  (e.g.,  indicator  light,  scalar  displays,  etc.). 

(1)  Subtype  (e.g.,  PPI  scan,  A  scan,  B  scan,  etc.). 

Any  category  of  the  human  performance  taxonomy  can  be  made  to  interact  with  any 
equipment  category  so  that,  for  example,  the  generic  task  for  visual  functions  (e.g., 
detect  presence  of  one  or  more  stimuli)  can  be  made  to  interact  with  the  equipment 
subtype  (e.g.,  PPI  radar  scan).  Indeed,  the  two  categories  of  human  performance  and 
equipment  must  interact  to  provide  a  meaningful  description  of  an  HFE  activity,  since  the 
latter  is  defined  in  terms  of  both  performance  and  equipment. 

The  taxonomy  classifies  only  those  data  descriptive  of  human  performance  in 
interaction  with  equipment.  As  can  be  seen  in  Appendix  A,  the  HFE  data  retrieval  system 
will  contain  much  more  than  human  performance  data  (e.g.,  analytic  and  evaluation 
techniques,  applicable  instructions  and  standards,  checklists,  etc.).  Classification  of  the 
material  in  Appendix  A  follows  typical  indexing  practices. 

Data  Formats 

The  proposed  HFE  data  system  has  three  tracks.  Track  1,  designed  specifically  for 
the  sophisticated,  specialist  user,  will  present  the  data  of  each  study  or  empirical  data- 
collection  situation  on  a  study-by-study  basis  in  the  form  of  abstracts  of  the  individual 
studies.  Users  queried  by  Blanchard  (1972)  desired  very  detailed  data  so  that  they  could 
judge  the  relevance,  applicability,  and  utility  of  the  material  presented  to  them.  Track  1 
data  would  presumably  satisfy  those  desires. 
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More  conventional  presentation  of  data  involves  the  synthesis  of  data  into  summary 
statements  of  the  form  "Use  LED  components  to  display  the  following  .  .  .  .  "  (Note  that 
such  a  statement  would  probably  be  based  on  at  least  one  empirical  study  that  would  be 
reported  as  an  individual  study  in  the  Track  1  format.)  It  is  assumed  that  users  of  the 
data  system  who  are  less  sophisticated  or  are  pressed  for  time  will  prefer  material  in  this 
format,  which  is  termed  Track  2. 

Because  the  data  in  Track  2  simply  summarize  data  already  presented  in  longer  form 
in  Track  1  and  will  be  cross-indexed  to  the  Track  1  data,  users  will  be  able  to  skip  between 
tracks  as  desired.  They  might  call  out  a  topic  in  Track  2  and,  desiring  more  information, 
might  switch  to  Track  1,  calling  up  all  the  studies  related  to  the  summary  data  they  read 
in  Track  2. 

Much  of  the  data  system  contents  (e.g.,  standards,  techniques,  etc.;  i.e.,  tutorial 
material)  will  not  be  appropriate  to  either  of  these  formats  and  will  be  placed  in  what  is 
termed  Track  3. 

Examples  of  the  format  of  Tracks  1,  2,  and  3  are  shown  in  Appendix  B. 

Track  1 


The  data  format  for  Track  1  follows  in  general  that  recommended  by  Blanchard 
(1972).  The  individual  study,  referred  to  as  the  data  insert  (DI),  is  the  basic  data 
storage/retrieval  unit  of  the  data  system,  Track  1. 

The  DI  is  organized  into  three  functional  sections:  (1)  index  and  coding  information, 
(2)  data  source  description  and  salient  performance  shaping  factors,  and  (3)  data 
presentation  graphics  (see  Figures  B-1--B-3).  A  description  of  each  DI  element  follows: 

1.  DIN.  Data  insert  number  preceded  by  a  "1"  to  represent  Track  1. 

2.  Environment/system  (E/ST).  Environment  within  which  the  data  were  collected 
and  type  of  system  (if  identifiable).  Coding  is  accomplished  by  combining  one  or  more  of 
the  following  descriptors: 

a.  Operational  or  nonoperational.  If  operational,  circle  one  of  the  following 

items: 


(1)  Environment. 

(a)  Airborne  (AIR) 

(b)  Sea  surface  (SUR) 

(c)  Ground  based  (GRB) 

(d)  Subsurface  (SUB) 

(2)  System. 

(a)  Attack  (ATK) 

(b)  Antisubmarine  warfare  (ASW) 

(c)  Antiair  warfare  (AAW) 

(d)  Command/control  (CIC) 

(e)  Communications  (COM) 

(f)  Electronic  warfare  (ELT) 
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(g)  Mining  (MIN) 

(h)  Navigation  (NAV) 

(i)  Reconnaissance  (REC) 

(j)  Surveillance  (SRV) 

3.  Variable  class.  Class  of  independent  variables  investigated  systematically  in  the 
DI.  Classes  and  associated  codes  are: 

a.  Operational  (OP) 

b.  Equipment  (EQ) 

c.  Task  (TS) 

d.  Personnel  (PR) 

e.  Environmental  (EV) 

4.  Data  source.  Data  in  the  DI  were  obtained  from  the  following  sources: 

a.  Operational  data/instrumented  systems  (S- 1 ) 

b.  Fleet  exercise  data  (S-2) 

c.  Dynamic  simulation  (S-3) 

d.  DoD  related  HF  laboratory  studies  (S-4) 

e.  Program-directed  data  collection  studies  (S-5) 

f.  Experimental  research  literature  (S-6) 

g.  Subjective  judgment  studies  (S-7) 

h.  Design  support  studies  (S-8) 

i.  Nonperformance  data  (S-9) 

5.  DIN  reference.  The  original  report  or  document  from  which  data  were  extracted 
for  the  DI,  which  is  included  in  the  data  system  bibliography. 

6.  Related  DINs.  An  optional  category  that  allows  for  other  DINs  to  be  included  in 
the  DIN. 

7.  Process.  The  generic  function  performed  by  study  personnel  (e.g.,  visual, 
auditory,  etc.)  that  brings  the  behavior  down  to  a  more  concrete  level. 

9.  Generic  task.  Relatively  concrete  human  activity  performed  by  study  personnel 
(e.g.,  locate  stimulus  in  field  with  other  stimuli). 

10.  System  reference.  Study  applicable  to  particular  type(s)  of  Navy  system(s). 

11.  Data  description.  Description  of  the  situation  in  which  data  were  collected, 
including  such  items  as  stimuli  presented,  responses  required  of  personnel,  equipment 
details,  presentation  rate,  etc. 

12.  Data  dimensions.  Key  aspects  of  the  study  used  as  weighted  descriptors  for  data 
retrieval. 

13.  Task  factors.  Characteristics  of  the  task  performed  in  the  study  that  might 
modify  the  performance  data  collected. 

14.  Personnel  factors.  Characteristics  of  the  study  personnel  that  might  modify  the 
performance  data  collected. 
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15.  Environmental  factors.  Characteristics  of  the  environment  in  which  the  data 
were  collected  that  might  have  affected  those  data  (e.g.,  in  a  display  situation,  the 
amount  of  ambient  lighting). 

16.  Test  results.  What  was  learned  from  this  study  including  specific  performance 
data  relationships  in  graphic/tabular  form,  significance  levels  achieved,  etc. 

17.  Interpretation.  Conclusions  reached  from  the  study. 

18.  Applicability.  Evaluation  of  the  adequacy  of  the  study  to  serve  as  the  basis  of 
generalization.  The  kinds  of  questions  the  study  will  answer. 

Track  2 


Track  2  presents  essentially  narrative  descriptions  with  graphs,  tables,  etc.  Track  2 
contains  much  of  the  same  data  as  does  Track  1  and  the  studies  referred  to  in  the  Track  2 
description  will  be  cross-referenced  back  to  DIN  items  in  Track  1;  however,  the 
combination  and  summarization  of  material  in  Track  2  does  not  lend  itself  to  the  Track  1 
outline  type  of  format.  The  DINs  for  Track  2  start  with  "2."  For  computerized  data 
retrieval,  the  Track  2  material  will  be  coded  for  process,  function,  generic  task,  data 
source,  etc. 

Track  3 


Track  3  includes  all  other  ancillary  information  such  as  HFE  specifications  and 
standards,  analytic  and  evaluation  techniques,  etc. 

1.  DIN.  Data  insert  number  preceded  by  "3"  to  represent  Track  3. 

2.  Topic. 

a.  Title  of  material 

b.  Instructions  for  data  system  use 

c.  Instructions/standards 

d.  Techniques— analytic 

e.  Techniques— predictive 

f.  Techniques— evaluation 

g.  Design  principles: 

(1)  Controls 

(2)  Displays 

(3)  Display  characteristics 

(4)  Workplace 

(5)  Anthropometry 

(6)  Environment 

(7)  Habitability 

(8)  Maintainability 

h.  Human  performance  prediction  data 

i.  Personnel  availability  and  cost 

j.  References 
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Each  of  these  topics  may  be  broken  down  further  as  appropriate;  for  example,  by  type 
of  control  or  display,  particular  environment,  or,  for  anthropometry,  the  part  of  the  body 
being  considered.  There  will  be  no  further  categorization  beyond  this  sub-breakout. 

Data  Analyses 

Data  for  the  second  track  will  be  manipulated  to  derive  generalizations.  This  will  be 
possible  only  if  the  study  data  were  gathered  under  similar  conditions  so  that  it  is 
reasonable  to  combine  the  data.  It  may  be  necessary  to  transform  the  data  from  several 
studies  into  a  common  metric  if  a  common  measure  was  not  initially  used.  The  following 
data  manipulations  are  possible: 

1.  Conversion  of  data  to  a  common  metric. 

2.  Extrapolation  of  data  to  new  points  on  a  continuum.  For  example,  if  the  data 
available  describe  only  points  1-10  on  the  scale,  it  may  be  desirable  to  extend  the  curve  to 
extrapolate  the  data  to  points  11-15. 

3.  Modification  of  data  to  take  into  account  "performance  shaping  factors."  For 
example,  it  is  well  known  that  stress  changes  performance.  Based  on  the  information 
known  about  stress  effects,  error  rates  or  task  accomplishment  indices,  etc.  may  be 
changed  to  reflect  that  stress  effect.  This  was  done  in  the  development  of  the  AIR  data 
store  (Payne  <5c  Altman,  1962)  and  by  Swain  and  Guttmann  (1980). 

4.  Generalization  of  data.  For  example,  if  considering  the  data  as  a  whole  suggests 
an  inverted  U  relationship  that  no  single  study  has  demonstrated,  it  is  appropriate  for  the 
data  system  developer  to  suggest  that  such  a  relationship  exists  because  of  the  burden  of 
the  evidence. 

In  addition,  material  accompanying  the  data,  such  as  design  recommendations, 
comments  on  the  quality  of  the  data,  confidence  in  the  generalizations,  etc.,  will  be 
provided. 

In  the  first  track,  data  from  several  studies  could  be  combined  if  the  important 
aspects  of  the  behavioral  data  collection  situations  were  similar.  As  this  rarely  happens, 
combining  data  in  the  first  track  seems  unlikely.  It  is  possible  to  combine  data  in  the 
second  track  because  the  approach  to  the  presentation  of  data  is  more  molar,  less  finely 
grained.  Since  the  unsophisticated  user  is  looking  more  for  generalizations  than  for 
detail,  the  "broad  brush"  treatment  of  the  data  permits  greater  freedom  in  data 
manipulation,  extrapolation,  and  generalization. 

Prototype  Data  Base 

Emphasis  during  FY83  was  on  Track  2  material,  which  could  be  developed  with  less 
effort  and  funding  than  Track  1  material.  The  scope  of  the  project  was  also  reduced  in 
FY83  by  establishing  an  area  of  subject  matter  concentration  in  which  many  studies  have 
been  performed  over  the  years.  Electronic  visual  displays  were  selected  as  an  area  of 
data  base  concentration  because  their  design  is  important  to  all  modern  Navy  weapon 
systems. 


The  following  topics  were  included  in  the  initial  prototype  data  base: 
1.  Section  1.  Introduction  and  approach  to  display  design. 


2.  Section  2.  Definitions  and  specifications  of  visual  display  parameters. 

3.  Section  3.  CRT-PPI  (planned  position  indicator)  displays. 

4.  Section  4.  CRT-TV  (television)  displays. 

5.  Section  5.  New  technologies  (e.g.,  forward  looking  infrared). 

6.  Section  6.  Matrix  displays. 

7.  Section  7.  Coding  of  symbols. 

8.  Section  8.  Environmental  effects  on  human  performance  with  displays. 

9.  Section  9.  Human  performance  using  displays  in  continuous  operations. 

Data  Retrieval  Procedures 

Hard  Copy  Retrieval 

Initially,  the  data  system  will  be  in  book  form  and  user  access  to  the  system  will  be 
via  an  index.  Because  the  system  is  composed  of  three  tracks,  there  will  in  fact  be  three 
individual  indices,  one  for  each  track.  Each  index  will  have  three  parts: 

1.  Subject  classification. 

2.  DIN  (data  insert  number). 

3.  Page  numbers  corresponding  to  the  DIN. 

In  Track  1,  retrieval  is  first  by  process,  function,  and  generic  task.  For  example,  all 
perceptual  (process)  DINs  are  listed.  A  subclassification  under  perceptual  might  be 
visual-perceptual  with  its  associated  DIN  and  page  numbers.  The  typical  user  would  be 
most  interested  in  the  generic  task  classification  (e.g.,  locate  stimulus  in  field  with  other 
stimuli).  Table  2  presents  examples  of  this  type  of  indexing  and  of  indexing  by  key 
dimensions,  another  section  of  the  Track  1  index.  The  entries  in  this  part  of  the  index 
would  be  alphabetized.  There  would,  however,  be  no  subclassifications  (e.g.,  workload 
under  the  category  of  specific  displays). 

It  would,  therefore,  be  possible  to  identify  a  DI  in  terms  of  process,  function,  generic 
task,  and  all  key  dimensions.  Retrieval  would  be  in  terms  of  subject  matter.  Having 
identified  the  page  numbers  of  the  data  items  of  interest,  the  system  users  would  turn  to 
the  pages  of  interest. 

Because  the  Track  2  indexing  scheme  closely  follows  that  of  Track  1,  it  would  be 
possible  to  commingle  the  indexing  for  Tracks  1  and  2  with  references  to  process, 
function,  and  generic  task  except  that  it  might  complicate  the  reference  process  for  the 
user. 

Track  3  indexing  will  follow  a  traditional  indexing  procedure  in  which  alphabetized 
subject  matter  headings  (topic,  title,  and  subtitle)  are  matched  with  DINs  and  page 
numbers.  In  Track  3,  the  subcategories  and  cross  references  found  in  the  typical  technical 
book  will  be  permitted. 

Computerized  Data  System 

It  might  be  possible  to  specify  the  data  retrieval  characteristics  a  computerized 
system  should  have,  but,  in  view  of  the  considerable  development  that  will  be  required 
before  such  a  system  can  be  instituted,  it  is  considered  wiser  to  postpone  consideration  of 
this  aspect  until  later. 


Table  2 


Index  by  Process,  Function,  and  Generic  Task  and  by  Key  Dimensions 


Classification 

DINa 

Page  Number 
in  Hard  Copy 

Process, 

Function,  and  Generic  Task 

Perceptual 

11-189 

32-115 

Visual 

11-132 

33-75 

Locate  stimuli 

11-110 

33-43 

Detect  stimulus 

11-118 

44-51 

Detect  movement 

111-128 

52-61 

Cognitive 

100-133 

116-159 

Information  processing 

90-133 

116-159 

Calculate 

116-133 

142-159 

Key  Dimensions 

Air  traffic  control 

137 

123 

Radar 

1 14,  123,  129,  etc. 

111,  116,  142,  etc. 

Visual  detection  of  change 

153,  162,  179 

115,  133,  178 

Workload 

156,  162,  177,  179 

144,  162,  168 

aDIN  =  Data  insert  number. 


FUTURE  EFFORTS 


Long-term  Plans 

Because  of  the  amount  of  material  to  be  organized,  full-scale  development  of  an 
effective  data  retrieval  system  must  be  a  multiyear  effort.  Because  each  of  the  many 
specialized  subject  areas  (e.g.,  controls,  displays)  that  must  be  considered  will  require 
experts  to  construct,  most  of  the  effort  must  be  performed  by  contractors. 

If  only  material  for  Tracks  2  and  3  were  to  be  implemented,  it  might  be  feasible  for  a 
single  contractor  to  develop  the  necessary  materials.  Track  1  material,  however,  requires 
detailed  examination  and  critique  of  individual  studies  and  probably  no  single  contractor 
will  have  the  necessary  expertise  to  handle  all  aspects  of  the  system.  This  suggests,  then, 
multiple  concurrent  contracts  for  developing  individual  sections  or  groups  of  sections  with 
NAVPERSRANDCEN  coordinating  the  individual  contractors  and  maintaining  quality 
control  over  their  efforts. 

It  is  suggested  that  the  proposed  system  be  developed  over  the  period  FY84  through 
FY88  with  funding  at  the  rate  of  approximately  $250,000  to  $300,000  each  year. 


The  following  steps  would  be  performed: 

1.  Document  main  sources  and  accession  information  for  HFE  design  support  data. 

2.  Develop  procedures  for  testing  the  utility  of  the  prototype  data  system. 

3.  Conduct  initial  tests  and  revise  of  the  prototype  data  system. 

4.  Expand  data  system  to  additional  taxonomic  categories. 

5.  Develop  a  query  and  accession  system  for  HFE  data  sources. 

6.  Develop  and  implement  techniques  for  collecting  additional  behavioral  data  from 
operational  ships  and  environments. 

7.  Develop  front-end  analytic/evaluating  techniques  for  inclusion  in  the  data 
system. 

8.  Develop  procedures  for  computerizing  the  data  system. 

9.  Develop  NAVSEA  HFE  design  standard  for  implementing  HFE  design  and  testing 
criteria  into  the  design  of  new  ship  systems. 

10.  Implement  computerization  of  full-scale  HFE  data  system. 

11.  Test  computerized  data  system. 

12.  Develop  and  implement  procedures  for  incorporating  the  HFE  data  system  into 
the  weapon  system  acquisition  process. 

Major  sections  of  this  report  could  be  incorporated  into  an  informal  guide  for 
NAVPERSRANDCEN  to  use  in  coordinating  the  contractors  developing  sections  of  the 
system.  NAVPERSRANDCEN  would  also  develop  the  operational  data  sources  that  should 
provide  a  very  substantial  part  of  the  data  in  the  system.  Access  to  these  data  sources 
(e.g.,  fleet  exercises,  operator/maintainer  performance  indices,  etc.),  may  be  severely 
restricted  because  those  in  charge  of  Navy  ships  and  ship  data  may  view  collecting  the 
desired  information  as  a  potentially  negative  evaluation  of  their  efforts.  Hence,  using 
these  data  sources  will  require  a  major  effort  to  secure  access  to  Navy  ships  and  to  gather 
the  desired  information.  However,  unless  this  is  done,  the  human  performance  data  base 
will  consist  almost  entirely  of  the  experimental  research  literature.  NAVPERSRAND¬ 
CEN— not  a  contractor --must  open  up  the  operational  data  sources.  Much  of  the  funding 
for  this  project  in  the  "out"  years  will  be  required  for  this  effort  because  the  collection  of 
such  data  is  a  major  effort  in  itself. 

It  would  also  be  highly  desirable  to  involve  representatives  of  the  potential  users  of 
the  system  in  the  development  effort.  The  degree  to  which  this  involvement  will  be 
feasible  will  depend  on  user  cooperation,  which  cannot  at  this  time  be  predicted. 

Short-term  Plans 

Since  very  substantial  funding  is  required  for  the  implementation  of  the  full-scale 
system  (and  the  likelihood  that  all  the  funding  will  not  become  available),  i+  seems 
reasonable  to  concentrate  on  short-term  goals,  while  still  pursuing  the  long-term  g  .als  at 
a  somewhat  lower  level  of  effort. 
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OUTLINE  OF  HFE  DATA  RETRIEVAL  SYSTEM  CONTENTS 


I.  Instructions  on  how  to  use  the  information  retrieval  system. 

II.  Applicable  DoD  and  Navy  instructions/standards.  This  section  will  be  a  listing  of  the 
instructions,  standards,  and  specifications  that  describe  or  refer  to  HFE  and  related  areas, 
or  have  a  bearing  HFE  or  related  areas.  A  brief  description  of  the  instruction/standard 
will  be  appended  to  the  listed  item,  but  the  instruction,  standard,  etc.  will  not  be 
reproduced  in  its  entirety. 

A.  HFE 

B.  Maintainability 

C.  Other  (e.g.,  habitability,  lighting,  safety,  etc.) 

III.  HFE  analytic  techniques.  This  section  will  contain  short,  outline,  step-by-step 
procedures  of  major  HFE  analytic  techniques  with  an  example  of  each.  Descriptions  will 
include  when  the  technique  should  be  used  and  the  products  of  each  analysis. 

A.  General 

1.  Behavioral  questions  arising  in  system  development  for  which  analyses  are 
needed  (e.g.,  Will  personnel  be  able  to  perform  system  functions  adequately?). 

B.  Specific 

1.  Function  flow  analysis 

2.  Task  and  job  analysis 

3.  Operational  sequence  diagrams 

4.  Time  line  analysis 

5.  Information  analysis 

6.  Workload  analysis 

7.  Error  mode  and  effect  analysis 

8.  Link  analysis 

9.  Workplace  analysis 

IV.  HFE  evaluation  techniques.  This  section  will  contain  short,  outline,  step-by-step 
descriptions  of  the  major  evaluation  techniques. 

A.  General 

1.  Definition  of  evaluation,  phases  of  system  development  in  which  evaluation 
occurs,  types  of  evaluation. 

2.  Evaluation  questions  to  be  answered  in  system  development. 

3.  Evaluation  measures  available  (e.g.,  response  time,  duration,  etc.),  purposes 
for  which  used,  advantages/disadvantages. 

4.  Types  of  evaluation  tests. 

5.  DoD/Navy  regulations  concerning  developmental  and  operational  testing. 

6.  Products  to  be  evaluated  (e.g.,  drawings,  piocedures). 


7.  Mockups  and  how  to  use  them  for  evaluation. 

8.  Simulation  and  simulation  models  available  (e.g.,  CAFES). 

9.  Summary  of  experimental  design. 

10.  Test  planning  procedures  including  sample  test  planning  outline. 

B.  Specific 

1.  Sample  HFE/maintainability  checklist. 

2.  Sample  HFE/maintainability  questionnaire. 

3.  Sample  HFE/maintainability  interview  questions. 

4.  Observational  methods  (e.g.,  time  sampling). 

5.  Accident  report  data. 

6.  Critical  incidents. 

7.  Opinion  methods  (e.g.,  Delphi,  paired  comparisons,  etc.). 

8.  Self-report  methods  (e.g.,  diaries,  self-report  forms). 

9.  Automatic  measurement  methods,  (e.g.,  OPREDS). 

V.  Principles  of  control  selection  (uses  a  three-tier  taxonomy).  This  section  will 
prescribe  the  ground  rules  under  which  particular  types  of  controls  are  selected  by  the 
designer.  Organization  of  this  material  is  by  control  type.  Information  presented  includes 
specific  control  applications,  recommended  maximum/minimum  dimensions  and  special 
characteristics  (illustrated  by  drawings),  and  error  probabilities  associated  with  each  type 
of  control, 

A.  Hand  controls 

1.  Discrete  action 

a.  Pushbuttons 

b.  Toggle  switches 

c.  Rotary  selector  switches 

d.  Multiple  pushbuttons 

e.  Thumbwheels 

f.  Keysets 

g.  Keyboards 

2.  Continuous  action 

a.  Rotary  knobs 

b.  Handwheels 

c.  Handcranks 

d.  Levers 

e.  Joysticks  (pressure/displacement) 

f.  Track  ball 

g.  Thumb  controller 

h.  Sidearm  controller 

i.  Center  controller 
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3.  Foot  controls 

a.  Discrete  action 

b.  Continuous  action 

4.  Communications  equipment 

a.  Exterior  communications 

(1)  Radio-CW 

(2)  Radiotelephone 

(3)  Radioteletype 

(4)  Signal  light 

(5)  Signal  flags 

(6)  Amplified  voice 

b.  Interior  communications 

(1)  Telephone  systems  (electricai/sound) 

(2)  Announcing  systems 

(3)  Voice  tubes 

(4)  Electrical  alarm/ warning  systems 

(5)  Electrical  indicating/ordering  systems 

5.  Panels  and  consoles 

a.  Panels 

(1)  Metal  panels 

(2)  Transilluminated  panels 

(3)  Integrated  (mated)  panels 

b.  Configurations 

(1)  Contours/slopes  of  consoles 

(2)  Legends/labeling/coding 

VI.  Principles  of  display  selection/design  (uses  a  three-tier  taxonomy).  This  section  will 
be  organized  into  two  parts--type  of  display  and  display  characteristics.  Associated  with 
each  will  be  an  error  probability  and  the  human  performance  to  be  expected  with  the 
display  and  the  characteristic. 

A.  Visual  display 

1.  Indicator  lights  (transilluminated) 

a.  Single-status 

b.  Multiple-status 

c.  Lighted  pushbutton  displays 


2.  Sequential-access  digital  readouts 


a.  Electromechanical  drum  counters 

b.  Flag  counters 

3.  Random-access  digital  readouts 

a.  Segmented  matrices 

b.  Cold  cathode  tubes 

c.  Edge-lighted  plates 

d.  Projection  readouts 

e.  Back-lighted  belt  displays 

f.  Light-emitting  diode  (LED)  displays 


4.  Scalar  displays  (dials,  guages,  meters) 

a.  Moving-pointer,  fixed-scale 

b.  Fixed-pointer,  moving-scale 

5.  CRT  spatial-relation  displays 

a.  Radar  displays 

b.  Sonar  displays 


6.  CRT  alphanumeric/pictorial  displays 

a.  Computer  output  displays 

b.  Television  output  displays  (CCTV) 

c.  Infrared  sensor  displays 

d.  Low  light-level  TV  displays 

7.  CRT  electronic  parameter  displays 

a.  Waveform  displays 

b.  Bar  graph  displays 

c.  Analog  computer  output  displays 

8.  Status  displays 

a.  Plot  boards 

b.  Map  displays 

c.  Projected  displays  (static/dynamic) 

d.  Matrix  boards 

e.  Large  screen  displays 

9.  Hard-copy  readout  displays 

a.  Printers 

b.  Recorders 

c.  Plotters 


10.  Film 
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B.  Auditory  displays 


1.  Electromechanical 

a.  Bells 

b.  Buzzers 

c.  Horns 

d.  Sirens 

2.  Electronic 

a.  Electronic  tones/signals 

b.  Recorded  signals/directions  (tape) 

C.  Visual  display  characteristics 

1.  Specific 

a.  Alphabet  characters 

b.  Alphabet  words 

c.  Numeric  characters 

d.  Numeric  groups 

e.  Alphanumeric  words 

f.  Alphanumeric  groups 

g.  Unstructured  (e.g.,  PPI) 

h.  Coded 

i.  Photographic 

j.  Map  type 

k.  Tabular 

l.  Graphic 

2.  General 

a.  Color 

b.  Background  characteristics 

c.  Overaa  display  size 

d.  Stimulus  size 

e.  Phosphor  characteristics 

f.  Dynamic  characteristics 

(1)  Static 

(2)  Moving 

g.  Resolution 

h.  Density  of  stimuli 

i.  Stimulus  number 

j.  Number  of  stimulus  channels 

k.  Number  of  levels  of  information  per  channel 

l.  Rate  of  display  change 

m.  Frequency  of  stimulus  presentation 

VII.  iVsign  of  individual  and  multiman  workplaces 
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A.  General 

1.  Principles  of  workplace  design  analysis 

2.  Layout  principles 

3.  Standardization 

4.  Safety 

5.  Visibility  factors 

6.  Anthropometric  factors 

B.  Specific 

1.  Control/display  arrangement 

2.  Console  design 

3.  Working  areas 

4.  Seats 

5.  Doors  and  hatches 

6.  Stairs/ladders/ramps 

7.  Traffic  spaces 

VIII.  Performance  of  behavioral  functions  (uses  a  three-tier  taxonomy).  This  section  will 
describe  the  personnel  performance  to  be  expected  with  general  behavioral  functions  and, 
consequently,  is  organized  by  individual  functions.  Associated  with  each  of  the  functions 
listed  below  are:  (a)  error  probability,  (b)  limiting  values  (maximum/minimum)  (e.g., 
smallest  stimulus  that  can  be  perceived),  and  (c)  performance  as  a  function  of  relevant 
variables  for  which  data  exist.  Heavy  emphasis  will  be  given  to  graphic  and  tabular 
material. 

A.  Perceptual  processes 

1.  Visual 

a.  Detect  presence  of  one  or  more  stimuli  (radar  target,  indicator  light). 

b.  Detect  movement  of  one  or  more  stimuli. 

c.  Detect  change  in  basic  stimulus  presentation  (status,  alphanumeric). 

d.  Detect  variation  in  stimulus  characteristics  (color,  shape,  size). 

e.  Recognize  stimulus  characteristics  and  identify/classify  stimulus  types. 

f.  Locate  stimulus  in  a  field  containing  other  stimuli  of  varying  similarity. 

g.  Discriminate  two  or  more  stimuli  on  basis  of  relative  characteristics. 

h.  Read  materials  and  obtain  information/instructions. 

i.  Read  displays  and  obtain  alphanumeric  information. 

2.  Auditory 

a.  Detect  presence  of  one  or  more  aural  stimuli  (sonar  signal,  aural 

alarm). 

b.  Recognize  stimulus  characteristics  and  identify/classify  stimulus  types. 

c.  Detect  a  variation  or  change  in  stimulus  characteristics  (pitch,  ampli¬ 
tude,  harmonics). 

d.  Discriminate  two  or  more  stimuli  on  basis  of  relative  characteristics 
(pitch,  amplitude,  quality,  harmonics). 


3.  Tactile 

a.  Identify  control(s)  by  discriminating  among  various  shape  codes. 

B.  Perceptual-motor  processes 

1.  Discrete 

a.  Activate/set  one  or  more  controls  according  to  displayed  information. 

b.  Mark  position  of  objects)  on  a  device/surface  according  to  displayed 

information. 

c.  Manipulate  control  to  position  one  or  more  stimuli  at  a  discrete 
location  according  to  displayed  information. 

d.  Change  stimulus  characteristics  by  manipulating  control  (gain,  bright¬ 
ness). 

e.  Introduce  new  stimuli  or  remove  old  stimuli  by  manipulating  control 
(information  display  updating). 

2.  Continuous 

a.  Adjust  control(s)  to  maintain  coincidence  of  two  moving  stimuli  (pursuit 

tracking). 

b.  Adjust  control(s)  to  compensate  for  deviation  in  one  moving  stimulus 
(compensatory  tracking). 

c.  Input  data/information  by  manipulating  one  or  more  controls  (alpha¬ 
numeric  keyboard). 

d.  Align  two  or  more  stimulus  presentations  to  achieve  balanced  or 
steady-state  condition. 

e.  Regulate  the  level  or  rate  of  a  process,  event,  or  output  according  to 
displayed  information. 

C.  Motor  processes 
l.  Manipulative 

a.  Connect/disconnect  mated  objects. 

b.  Set  control(s)  to  predetermined  position. 

c.  Install  material/item  according  to  established  procedure. 

d.  Record  information  manually  using  writing  instrument. 

e.  Position  object  in  a  particular  physical  orientation  to  another  object(s). 


f.  Open/close  access  doors/hatches/plates. 

g.  Remove /replace  components  from  larger  units. 

2.  Movement 

a.  Transport  object  from  one  point  to  another. 

b.  Lift,  move,  set  object. 

c.  Locomote  from  one  point  to  another. 

d.  Throw  an  object  from  one  point  to  another. 

e.  Exert  force  on  an  object/body  (push,  pull,  press,  grip). 

D.  Cognitive  processes 

1.  Information  processing 

a.  Code/decode  stimuli  according  to  known  rules  and  principles. 

b.  Calculate/compute  indices/values  using  arithmetic. 

c.  Categorize/classify  stimuli  or  data  according  to  known  characteristics. 

d.  Compare  two  or  more  calculated  values  and  take  prescribed  action. 

e.  Interpolate/extrapolate  known  values  to  estimate  or  predict  event  or 

status. 

f.  Analyze  information  or  stimuli  where  alternatives  are  not  specified  as 
part  of  problem  information. 

2.  Decision-making/problem-solving 

a.  Select  course  of  action  from  two  or  more  options  based  on  stated  rules, 
principles,  guidelines. 

b.  Select  course  of  action  from  alternatives  when  routine  application  of 
rules  would  be  inadequate  for  optimal  choice. 

c.  Predict  the  occurrence  of  an  event  or  condition  using  various  sources  of 
displayed  and  recalled  information. 

d.  Estimate  the  characteristics  and/or  causal  relationships  of  stim¬ 
uli/events  by  transforming  existing  principles  into  specialized,  higher-order  guidelines. 

E.  Communication  processes  (primary  purpose  of  activity) 

1.  Request  information 


a.  Request  instructions/information  using  voice  communication  device. 

b.  Reqest  instructions/information  on  a  face-to-face  basis. 


c.  Request  instructions/information  using  coded  communication/interroga¬ 
tion  device. 

2.  Provide  information 

a.  Provide  advice/instructions/information  using  voice  communication  de¬ 
vice. 

b.  Provide  advice/instructions/information  on  a  face-to-face  basis. 

c.  Provide  advice/instructions/information  using  coded  communication  de¬ 
vice. 

3.  Listen  to  information 

a.  Listen  to  instructions/information  using  voice  communication  device. 

b.  Listen  to  instructions/information  on  a  face-to-face  basis. 

IX.  Anthropometric  tables.  This  section  will  contain  tables  of  anthropometric  values  for 
selected  parameters  and  is  not  intended  to  present  a  complete  set  of  such  tables  since 
their  number  would  be  excessive.  Tables  will  be  divided  into  static  and  dynamic 
dimensions. 

X.  Effects  of  environmental  factors  on  performance.  This  section  will  be  described  in 
terms  of  the  individual  factors  listed  below.  Each  factor  will  include  the  limiting  values 
(e.g.,  lethal  threshold,  threshold  of  pain)  and  human  performance  of  a  general  function 
like  vigilance  as  determined  by  one  or  more  factor  dimensions  (e.g.,  direction  of 
acceleration). 

A.  Temperature 

B.  Noise 

C.  Lighting 

D.  Vibration 

E.  Acceleration 

D.  Vibration 

E.  Acceleration 

F.  Air  movement 

G.  Diurnal  variations 

XI.  Habitability  design  for  ship  living  and  work  spaces.  This  section  presents  available 
design  principles  for  ship  habitability  design. 

A.  Habitability  of  living  spaces 

1.  Berthing 

2.  Sanitary  spaces 

3.  Messing 

4.  Environmental  control  (e.g.,  lighting,  temperature,  noise,  etc.) 

5.  Color  and  furniture 

6.  Habitability  design  processes 

B.  Habitability  of  working  spaces 
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XII.  Principles  of  maintainability  design.  This  section  presents  data  and  principles  for 
the  internal  design  of  equipment  and  the  personnel  implications  of  that  design. 

A.  Principles  of  maintainability  design 

1.  Accessibility 

2.  Packaging 

3.  Component  labeling 

4.  Connectors,  conductors,  and  fasteners 

5.  Automatic  test  equipment 

6.  Maintenance  procedures 

7.  Maintenance  job  aids 

B.  Maintainability  prediction 

1.  Available  methods 

2.  Mean  time  to  repair  for  common  equipment  components 

3.  Troubleshooting 

4.  Probabilities  of  task  accomplishment  for  preventive  and  corrective 
maintenance 

XIII.  Prediction  of  individual/team  performance.  This  section  describes  available 
methods  for  predicting  the  human  performance  reliability  (HPR)  of  system  personnel  for 
new  systems  and  also  includes  available  HPR  data  bank  information. 

A.  Available  methods 

1.  Technique  for  human  error  rate  prediction 

2.  Siegel's  multidimensional  scaling  method 

3.  AIR  data  bank 

B.  HPR  data  for: 

1.  Man-machine  components  (e.g.,  controls,  displays,  interfaces,  etc.). 

2.  Modifying  factors  such  as  age,  sex,  training,  experience,  intelligence, 
stress,  and  illness. 

3.  Examples  of  how  to  perform  HPR  predictions. 

XIV.  Personnel  availability  and  cost 

A.  Personnel  availability  data 

B.  Personnel  costs  per  rating 

XV.  References.  This  section  will  contain  additional  reading  for  each  section  above. 
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EXAMPLE  OF  TRACK  1  FORMAT 


DIN;  163 

E/ST;  Nonoperational 
Variable  class:  TS 
Data  source;  S-6 

DIN  reference;  Thackray  et  al.  The  effect  of  increased  monitoring  load  on  vigilance 
performance  using  a  simulated  radar  display.  Ergonomics.  1979,  529-539. 

Related  PINs;  N/A 

Process;  Perceptual 

Function;  Visual  detection 

Generic  task;  Detect  critical  stimulus  in  midst  of  constantly  moving  targets. 

System  reference;  Simulated  air  traffic  control  containing  computer-generated  alpha- 
numerics. 

Data  description:  Simulated  ATC  display  (17-inch  CRT)  in  console.  Simulated  radar 
sweep  line  made  one  complete  clockwise  revolution  every  6  seconds.  Targets  were  small 
rectangular  "blips"  representing  aircraft  locations.  Adjacent  to  each  target  was  an 
alphanumeric  data  blod<  with  two  rows  of  symbols:  top  row  (two  letters,  three  numbers) 
identified  aircraft,  bottom  row  (six  numbers)  indicated  altitude  and  ground  speed.  A  total 
of  48  male  university  students  were  randomly  assigned  to  three  groups  of  equal  size,  each 
group  differing  only  in  the  number  of  targets  (4,  8,  or  16).  Critical  signals  were  presented 
during  each  half  hour  of  the  2-hour  session.  Subjects  responded  to  critical  signal  by 
pressing  button  and  holding  light  pen  over  target. 

Data  dimensions;  (Weights  assigned  on  the  basis  of  relative  importance:  major  (1)  or 
minor  (2)) 

Visual  detection  of  change  (1) 

Radar  (1) 

Air  traffic  control  (1) 

Alphanumeric  stimuli  (2) 

Detection  latency  (1) 

Target  density  (1) 

Workload  (1) 

Performance  decrement  over  time  (1) 

Laboratory  study  (2) 

Male  student  subjects  (2) 

Simple  task,  low  stress  (2) 

Task  factors: 

Complexity:  simple 
Duration:  2  hours 


Load  stress:  low 
Time  stress:  low 


Personnel  factors: 


Skill  level:  low 
Motivation:  weak 
Experience:  none 
Training:  none 

Environmental  factors:  Indirect  lighting;  level  of  illumination  at  display,  21.5  lux. 

Test  results:  Figure  B-l  provides  mean  detection  latencies  for  three  target  densities  as  a 
function  of  successive  30-minute  periods.  Detection  latencies  increase  over  time  for  the 
16-target  condition,  but  not  for  other  target  conditions.  Errors  are  virtually  nonexistent 
over  all  conditions. 


30-MINUTE  PERIODS 


Figure  B-l.  Mean  detection  latencies  for  the 
three  target  density  conditions. 


Interpretation:  For  applicable  situations,  no  performance  decrement  either  in  detection 
latency  or  error  is  to  be  anticipated  for  moderate  target  density  (4-8  targets)  over  2  hours 
of  monitoring.  With  a  large  target  density  (16),  there  is  a  slight  increase  in  detection 
latency  with  monitoring  time,  but  the  increase  is  not  excessive. 

Applicability:  This  study  is  applicable  to  air  traffic  control  situations  in  which  the  visual 
stimuli  are  alphanumeric,  the  work  loading  is  low,  the  performance  measured  is  detection 
of  change,  and  the  variable  of  interest  is  performance  decrement  as  a  function  of  target 


EXAMPLE  OF  TRACK  2  FORMAT 


DIN:  2773 

E/ST:  Nonoperational 
Variable  class:  EQ 
Data  source:  S-6 
DIN  reference: 

Process:  Perceptual 
Function:  Visual 

Generic  task:  Identify  symbols  on  CRT 

System  reference:  Use  of  CRT.  Effect  of  TV  raster  scan  and  vertical  resolution  on 
symbol  resolution. 

Test  results: 

How  many  active  TV  lines  per  symbol  height  are  required  to  display  symbols? 

Figure  B-2  shows  the  results  of  three  studies  seeking  the  relationship  between  number 
of  active  scan  lines  per  symbol  height  and  the  accuracy  and  speed  of  symbol  identifica¬ 
tion.  All  indicate  that  a  minimum  of  10  raster  scan  lines  per  symbol  height  are  needed  for 
highly  accurate  identification.  In  fact,  some  reduction  in  accuracy  is  noted  when 
resolution  is  reduced  from  12  to  10  lines  per  symbol  height. 


PERCENT 

CORRECT 


Figure  B-2.  The  functional  relationship  between  number  of  TV  scan 
lines/symbol  height  and  identification  accuracy  (adapted 
from  the  data  of  DIN  16,  38,  92). 
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Rate  of  identification  exhibits  a  relationship  similar  to  that  for  accuracy,  as  shown  in 
Figure  B-3. 
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Figure  B-3.  The  functional  relationship  between  number  of  TV  scan 
lines/symbol  height  and  rate  of  identification  (adapted 
from  the  data  of  DIN  16,  38,  92), 

EXAMPLE  OF  TRACK  3  FORMAT 

DIN:  342 


Topic:  Techniques:  Analytic 


Human  factors  specialists  use  timelines  to  predict  the  incidence  of  time  and  errors 
for  two  purposes.  First,  they  permit  an  appraisal  of  time-critical  activities  to  verify  that 
all  necessary  events  can  be  performed.  Second,  they  provide  an  integrated  task-time 
chart  to  assess  the  occurrence  of  incompatible  tasks  and  to  serve  as  a  baseline  for 
workload  evaluation. 

The  most  common  source  of  material  for  a  timeline  analysis  is  a  detailed  level 
functional  flow  diagram  in  which  tasks  are  allocated  to  operators.  Timelines  are  most 
effectively  used  during  the  concept  formulation  phase  of  system  development,  after 
DSARC  I,  but  before  DSARC  II.  They  require  comparatively  little  time  to  develop  and 
are  only  moderately  complex.  They  are  equally  useful  for  analysis  of  gross  detailed 
operator  procedures  and  can  be  used  either  for  individual  operator  or  team  tasks,  as  long 
as  all  the  tasks  are  placed  on  a  single  time  base. 

A  typical  timeline  chart  is  shown  in  Figure  B-4.  Each  timeline  must  be  related  to  a 
higher  level  functional  requirement.  The  functional  flow  title  and  number  should  be 
indicated  on  the  timeline  sheet  for  reference.  Other  information  such  as  location  of  the 
function  and  the  type  of  function  are  desirable.  Each  of  the  subfunctions  or  tasks  are 
numbered  and  listed  along  the  timeline. 


NUMBER  OF  SCAM  LINES  PER  SYMBOL  HEIGHT 


Figure  B-4.  Sample  timeline  sheet, 
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